\chapter{Spécification de l'API d'authentification et de contrôle d'accès aux ressources}

\section{Implémenter le modèle de sécurité OrBAC au sein de XWiki.}

L'objectif de cette section est de décrire, OrBAC, son modèle de
sécurité et son mode de fonctionnement. Dans la deuxième
partie on présentera un cas d'utilisation implémentant OrBAC


\subsection{{Le modèle OrBAC (Organization Based Access Control)}}

\subsubsection{Object}

L'objectif d'OrBAC est d'introduire un niveau d'abstraction permettant
d'exprimer la politique de contrôle d'accès indépendamment
de son implémentation. OrBAC se repose sur les principes suivants~:


\begin{itemize}
	\item Structuration via l'entité organisation
	\item Deux niveaux d'abstraction
\begin{itemize}
	\item Niveau concret : sujet, action, objet
	\item Niveau abstrait : rôle, activité, vue
\end{itemize}

	\item Expression de permissions, d'interdictions et d'obligations
	\item Expression de contextes
\end{itemize}


OrBAC permet d'exprimer aussi bien les autorisations, que les
interdictions ainsi que les obligations/recommandations. On pourra
ainsi, grâce aux obligations, autoriser un utilisateur X à
accéder à un objet dans un contexte bien précis sous
condition qu'il effectue par la suite une action. Cette condition est
exprimé grâce aux obligations.



OrBAC permet de prendre en compte les contextes. Mais l'abstraction et
les contextes ne suffisent pas à définir tous les cas. En
effet, il y a toujours des exceptions qui confirment la règle. Il
peut arriver que pour des remplacements, lors de restructuration ou de
travaux collaboratifs, on ait besoin de déléguer son droit
à une personne qui ne le possède pas. OrBAC permet de
définir dans quel cadre peut s'effectuer cette délégation
(contexte exprimant la personne à qui on peut déléguer).
Grâce à l'abstraction, au contexte, à l'héritage et
à la délégation, OrBAC est un modèle simple à
gérer. Les utilisateurs peuvent accéder simplement aux
données qui leur sont autorisés.


\subsubsection{Les différentes entités d'OrBAC }

\paragraph{L'organisation} L'organisation est l'entité centrale dans le modèle OrBAC,
elle s'exprime à travers une politique définie selon deux
niveaux~:

\begin{itemize}
	\item Organisationnel ou abstrait~: dans ce niveau on définit la
politique de l'organisation indépendamment de son
implémentation.
	\item Implémentation ou concret~: ce niveau est dérivé du niveau
abstrait.
\end{itemize}


Cette façon d'organiser les deux niveaux dans OrBAC rend la
politique de l'organisation évolutive et reproductible. En effet,
cette politique ne nécessite aucun réajustement au niveau
concret qui pourrait introduire des incohérences difficilement
récupérables ; tout se fait au niveau organisationnel. Le
niveau concret est constitué de sujets, d'actions et d'objets. Le
niveau implémentation contient les rôles, les activités et
les vues. Le rôle (respectivement l'activité, la vue) est un
ensemble de sujets (respectivement d'actions, d'objets) sur lesquels
sont appliquées les mêmes règles de sécurité

\paragraph{Les sujets} Dans OrBAC les sujets correspondent aux différents profiles des uilisateurs au sein de l'organisation.


\paragraph{Les rôles}

L'attribution des droits d'accès à ces sujets se fait par le biais de la
structuration en rôles.

\paragraph{Les activités} Les activités correspondent aux divers services offerts par l'organisation.
Chaque activité est un ensemble des actions existant au sein de l'organisation. Exemple~: une activité PUBLICATION 
est un ensemble des actions~: ajouter, publier, notifier, transformer et remplacer.


\paragraph{Les objets et les vues~:} Dans OrBAC une vue est un regroupement d'un ensemble des objets.
Ce regroupement permet de limiter les règles de la politique de sécurité appliquées à une vue

\paragraph{Les contextes} Dans OrBAC, le contexte est défini pour une organisation, un sujet,
une action, des objets donnés. Les contextes permettent d'exprimer des permissions ou des interdictions
dans certaines circonstances.

Dans OrBAC on peut identifier plusieurs types de contexte

\begin{itemize}
\item{Contexte temporel} : Ce sont des contextes régissant la durée de validité
des privilèges.
\item{Contexte spatial} : Il peut être lié à l'appartenance à un réseau, ou la position géographique, ou
à toute autre situation spatiale.
\item{Contexte déclaré par l'utilisateur} : Ce type de contexte est activé, par
exemple, par le médecin en cas d'urgence, ou pour signaler que l'on effectue un audit. Dans ces cas
exceptionnels, des permissions peuvent être données alors qu'elles seraient interdites dans un cas normal.
L'utilisateur qui déclare le contexte est obligé en contrepartie de faire un compte-rendu des
opérations effectuées et peut être des raisons qui l'on motivé à déclaré ce contexte.
\item{Contexte pré requis} : Leur utilisation permet de contraindre les sujets concernés par les
permissions ou les interdictions dépendant de ces contextes et qui vient réduire ou étendre les droits d'accès hérités du
rôle associé.
\item{Contexte provisionnel} : Ce contexte donne des privilèges en fonction de l'historique. Par exemple, le
contexte "accès limités à 2 fois" regarde si le document a été accédé au moins 2 fois.
\end{itemize}

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/img0}
  \caption{Rôle / Activité / Vue}
  \label{fig:rav}
\end{figure}


Sur le schéma~\ref{fig:rav}, on voit clairement les deux niveaux d'OrBAC ainsi que les entités de chacun.
L'organisation est au c\oe{}ur du modèle d'OrBAC. Quant au contexte, il joue le rôle de configuration des
entités du niveau concret par rapport à un temps donné. 

\subsection{Définition  de l'interactivité dans OrBAC }

\subsubsection{La notion de hiérarchie et de l'héritage}

 Afin de gérer plus facilement des sous-organisations, en automatisant la dérivation des
permissions, OrBAC permet de définir des hiérarchies sur les rôles, les activités, les vues et les contextes.
On a ainsi l'héritage des permissions et des interdictions en descendant dans la hiérarchie des rôles, des
activités, des vues et des contextes.

Il existe deux façons de définir la hiérarchie de l'héritage

\paragraph{Hiérarchie organisationnelle}

Le directeur est hiérarchiquement supérieur à un ingénieur. Dans certains cas, il peut donc hériter de toutes
les permissions de ce rôle (pour vérifier le travail de celui-ci). On dit alors que R1 est senior de R2 et R2 est junior
rôle de R1, si un utilisateur jouant le rôle R1 est supérieur hiérarchique de R2.

\paragraph{Spécification / généralisation} Elle est définie telle que R1 est un senior rôle de R2 si
chaque fois qu'un utilisateur joue le rôle de R1, il joue le rôle de R2. Donc à chaque fois qu'un utilisateur est
associé au rôle de directeur, il joue aussi le rôle de l'ingénieur. Le rôle directeur est un senior rôle de
rôle ingénieur. Un rôle R1 senior de R2 hérite donc les permissions affectées à R2.

Avec le modèle OrBAC, on peut définir des permissions mais
aussi des interdictions. Dans OrBAC, on peut aussi spécialiser un
rôle. On voit donc appara\^{\i}tre une hiérarchie liée
à cette spécification. Dans cette hiérarchie si on veut
qu'un rôle senior puisse avoir plus de pouvoir que son rôle
junior, alors il faut que le rôle senior hérite des permissions
de son rôle junior et que les interdictions liées au rôle
senior soient héritées par son rôle junior.

\subsubsection{La notion de délégation}

La délégation permet de donner à un utilisateur
particulier un privilège, sans donner ce privilège à toutes
les personnes ayant le même rôle que lui. La
délégation, bien que très utilisée, est très peu
modélisée dans les politiques de sécurité car ce
concept est très complexe.

En effet, grâce à une délégation, une permission peut
être donnée par le détenteur d'un droit à un tiers pour
agir à sa place ou à la place d'un autre. On voit déjà
ici appara\^{\i}tre qu'une délégation peut faire intervenir
plusieurs parties :

\begin{itemize}
	\item Le sujet qui possède le privilège 
	\item Le sujet a qui on délègue le privilège
	\item Le sujet qui délègue le privilège (pour agir à sa
place ou à la place d'un autre)
\end{itemize}

Il existe trois types de situation dans lesquelles la notion de
délégation appara\^{\i}t :

\begin{itemize}
	\item la maintenance d'un rôle
	\item la décentralisation de l'autorité
	\item le travail de collaboration
\end{itemize}


La délégation pourrait être effectuée sous plusieurs
formes~:

\begin{itemize}
	\item \uline{Délégation temporaire/permanente}~: l'utilisateur
délègue ses droits à un autre d'une manière
pérennante ou temporaire.
	\item \uline{Délégation monotone/non-monotone} : l'utilisateur perd
(monotone) ou non (non-monotone) ses droits lorsqu'il les
délègue.
	\item \uline{Délégation totale/partielle} : On peut choisir de
déléguer partiellement ou totalement un ensemble de droits.
	\item \uline{Délégation par agent/auto-active} : Il y a deux
façons d'administrer la délégation, si une personne X veut
déléguer un droit à Y. La première solution est que
c'est X qui administre la délégation. C'est la
délégation auto-active. La deuxième solution est que X
demande à un agent d'affecter ce droit à Y. C'est la
délégation par agent. L'agent pouvant être n'importe quelle
tierce personne dans l'organisation. Généralement, l'agent ne
peut pas s'affecter les droits qu'il gère. Il est possible de
définir le nombre de sous-délégation possible.
	\item \uline{Délégation à un-pas/à pas-multiple} : Dans la
délégation à n-pas, un même droit pourra être
délégué à une cha\^{\i}ne de n personnes. Par exemple,
X délègue à Y un droit D à 2-pas et Y délègue D
à 1-pas à Z.
	\item \uline{Délégation simple/multiple} : De plus, il faut choisir
si lorsqu'on autorise une personne à déléguer, elle peut
elle-même déléguer son droit à une unique personne, ou
à plusieurs personnes (c'est la délégation multiple).
	\item \uline{Délégation par accord unilatéral/bilatéral} :
Pour déléguer un droit, il faut qu'au moins une personne donne
son accord. On peut envisager deux types d'accord pour la
délégation. L'accord unilatéral ne prend en compte que la
décision de la personne désirant déléguer son droit.
L'accord bilatéral vérifie que les deux parties, celle qui
délègue et celle qui reçoit, sont d'accord.
	\item \uline{Révocation de la délégation simple/en cascade} : Si
la délégation est temporaire, il faut pouvoir la révoquer.
On a pu voir précédemment deux types de délégation
jouant sur la révocation. Lorsque la délégation est
"grant-dependant" alors seule la personne à l'origine de la
délégation peut ôter ce droit. Quand la délégation
est de type "grant-independant" seules les personnes ayant engendré
la délégation d'un droit à une personne peuvent lui
révoquer ce droit. Cependant, la personne, dont les droit ont
été révoqués, a peut être pu déléguer ce
droit auparavant. Cette situation peut poser des problèmes dans
certains cas. Selon le type de délégation, la personne ayant
était déchue d'un droit peut récupérer ce droit
grâce à une personne à qui elle aurait délégué
le droit. Pour anticiper ce problème, on peut créer deux types
de révocation. Un premier type permet de ne révoquer le droit
qu'à une personne désignée. Le deuxième type permet de
révoquer le droit sur une personne, ainsi que sur toutes les
personnes ayant reçu ce droit par délégation, c'est une
révocation en cascade.
\end{itemize}


\subsection{Définition d'une politique du controle d'accès }

\subsubsection{Introduction des permissions }


Permission (Organisation, Rôle, Activité, Vue, Contexte)  Les interdictions et les obligations sont définis de la même
façon.

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/img1}
  \caption{Le contrôle d'accès selon OrBAC}
  \label{fig:orbac-controle}
\end{figure}


\subsubsection{Cas d'utilisation~: politique de sécurité réseau}

Une organisation (Org) souhaitant définir une politique de
sécurité en s'appuyant sur le modèle OrBAC. L'organisation
en question dispose de la configuration suivante~:


\begin{itemize}
	\item des hôtes locaux pouvant accéder à l'Internet
	\item des hôtes externes ne peuvent accéder au réseau sauf en
passant par le serveur DMZ
	\item l'interface de firewall n'est pas accessible que par l'hôte
affecté au rôle de gestion de firewall
\end{itemize}


\paragraph{Hiérarchiser l'organisation Org}

Pour hiérarchiser une organisation (Entreprise, Organisme social, etc.) il faut 
identifier les entités en charge de gérer les règles de sécurité. Aussi il faut noter que la façon de hiérarchiser
une organisation dépend profondément de la politique de sécurité à mettre en place.

Selon le besoin défini ci-dessus pour l'organisation Org, on peut adopter le schéma hiérarchique suivant~:


\begin{itemize}

\item{Le réseau local de l'organisation Org\_LAN}
\item{La passerelle externe Org\_fwe : le firewall1}
\item{La passerelle interne Org\_fwi : le firewall2}
\item{Le serveur de base de données Org\_database}
\item{L'administration des passerelles Org\_admin\_fw}
\item{Internet Public\_net : réseau public (vue par Org comme un rôle)}
\end{itemize}


\paragraph{Les rôles}

\begin{itemize}
	\item \textit{Public\_host} : rôle pouvant être joué par un
hôte de la zone public
	\item \textit{Private\_host} : rôle pouvant être joué par un
hôte de la partie privée du réseau de l'organisation hors
zones d'administration
	\item \textit{Int\_firwall} : rôle pouvant être joué par les
interfaces du firewall frontal
	\item \textit{Web\_serveur} : rôle joué par le serveur de web
	\item \textit{Adm\_fw\_host} : rôle joué par les hôtes
d'administration des passerelles.
\end{itemize}


Les rôles définis dans l'organisation\textit{ Org} n'ont pas
forcément un sens pour toutes les sous-organisations d'Org.


\begin{itemize}
	\item Exemple : le rôle conseiller financier dans une banque B
\begin{itemize}
	\item Il est défini dans l'organisation \begin{math}B \end{math}
	\item Il est défini dans la sous-organisation
\textit{Private\_net\_clientèle }de \textit{Org\_private\_net} (Ex
: guichetier, responsable\_clientèle)
	\item Il ne l'est pas dans la sous\_organisation
\textit{Private\_net\_employé\_sg de Org\_private\_net }(Ex :
vigile, technicien de surface)
\end{itemize}

\end{itemize}

Les rôles définis dans l'organisation Org\_LAN ne sont pas
forcément définis dans ses sous-organisations Org\_fwe et
Org\_fwi.

\vspace{3pt} \noindent
\begin{tabular}{|p{139pt}|p{128pt}|p{116pt}|}
\hline
\parbox{139pt}{\raggedright 
\textit{Nom\_rôle }
} & \parbox{128pt}{\raggedright 
\textit{Org\_fwe}
} & \parbox{116pt}{\raggedright 
\textit{Org\_fwi}
} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Public\_host}
} & \parbox{128pt}{\raggedright 
X
} & \parbox{116pt}{\raggedright 

} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Private\_host}
} & \parbox{128pt}{\raggedright 

} & \parbox{116pt}{\raggedright 
X
} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Ext\_firewall}
} & \parbox{128pt}{\raggedright 
X
} & \parbox{116pt}{\raggedright 
X
} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Mail\_server}
} & \parbox{128pt}{\raggedright 
X
} & \parbox{116pt}{\raggedright 
X
} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Multi\_serv}
} & \parbox{128pt}{\raggedright 
X
} & \parbox{116pt}{\raggedright 
X
} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Adm\_fw\_host}
} & \parbox{128pt}{\raggedright 
X
} & \parbox{116pt}{\raggedright 
X
} \\
\hline
\parbox{139pt}{\raggedright 
\textit{Adm\_serv\_host}
} & \parbox{128pt}{\raggedright 

} & \parbox{116pt}{\raggedright 
X
} \\
\hline
\end{tabular}
\vspace{2pt}


\paragraph{Les permissions }

\textit{Org\_LAN\_permissions}

\begin{itemize}
	\item Permission : Org ( rôle ( activité ( vue ( contexte
	\item Permission(Org\_LAN,
admin\_fw\_host,admin\_to\_gtw,to-target(firewall), default)
	\item Dans l'organisation \textit{Org\_LAN}, un hôte jouant le rôle
d'administrateur des firewalls a la permission d'utiliser les services
d'administration des firewalls en toutes circonstances
	\item Permission (Org\_LAN, admin\_server,all\_tcp,to-target(multi\_server),
default)
	\item Permission (Org\_LAN, private\_host,https,to-target(web\_server),
default)
	\item Permission (Org\_LAN, public\_host,smtp,to-target(mail\_server),
default)
\end{itemize}


\textit{Org\_fwe\_permissions}

\begin{itemize}
	\item Permission(Org\_fwe,
admin\_fw\_host,admin\_to\_gtw,to-target(ext\_firewall), default)
	\item Permission(Org\_fwe,public\_host,smtp,to-target(mail\_server),
default)
\end{itemize}

\subsection{Introduire MotOrBAC }

Il s'agit d'une application prototype mis à la disposition des
administrateurs afin qu'ils puissent définir leurs politiques de
sécurité en se basant sur le modèle OrBAC.



Ce prototype est composé de quatre modules :
\begin{itemize}
\item L'analyseur de cohérence de la politique
\item La sauvegarde des données (en XML ou Prolog)
\item Le module de communication
\item L'interface graphique
\end{itemize}

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/img2}
  \caption{L'architecture de MotOrBAC}
  \label{fig:motorbac}
\end{figure}




\subsubsection{Les cinq fonctionnalités principales de MotOrBAC}

Saisie d'une politique de sécurité : l'administrateur peut
introduire avec MotOrBAC les différentes entités
spécifiques au SI dont il gère la sécurité
(organisations et sous-organisations, rôles, activités, vues et
contextes) et les règles de sécurité associées.

Simulation de la politique : MotOrBAC permet de simuler la politique
en saisissant les sujets, actions et objets de l'organisation et en
dérivant automatiquement la politique au niveau concret à
partir de la politique organisationnelle introduite par les
administrateurs. Les sujets, actions, objets sont caractérisés
par des attributs.

Vérification de la cohérence de la politique de
sécurité : MotOrBAC permet de détecter les conflits au
niveau concret ou abstrait de la politique de sécurité
spécifiée par l'administrateur.

Résolution de conflits : une fois des conflits détectés,
MotOrBAC intègre des stratégies de résolution de conflits
qu'il applique à la politique de sécurité introduite par
l'administrateur pour rétablir la cohérence.

Gestion des droits d'administration : MotOrBAC permet de spécifier
les droits donnant à un sujet affecté à un
rôle d'administration la possibilité de gérer tout ou
partie d'une politique de sécurité.






\section{Gestion des identités dans XWiki}


Cette section décrit les règles de gestion des identitées sur un réeseau P2P, il s'inscrit dans le cadre du projet XWiki. Il réepond aussi aux questions poséees par les difféerents acteurs du projet concernant les difféerents aspects de séecuritée sur le produit XWiki, notamment la gestion des identitées, la multiplication des identitées sur les serveurs ou par les utilisateurs.

La gestion des identités utilisateurs est un sujet majeur sur XWiki, spéecialement en absence d'un serveur centralisant les donnéees des utilisateurs. La question donc se pose de la manière suivante : comment peut-on protéeger  les identitées des utilisateurs sur un réeseau déecentralisée tel que XWiki ?
Plusieurs solutions sont envisageables. En effet, je préesente dans ce document le concept de gestion des identitées sur un réeseau P2P. \`A noter que dans le premier livrable de l'éetat de l'art de la séecuritée durant la phase T1, plusieurs produits ont éetée préesentées et qui réepondent à ce problème, on peut mentionner dans ce cadre là, OpenID comme un produit open source.



\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/fig1}
  \label{fig:fig1}
\end{figure}

Sur le schéma~\ref{fig:fig1} on voit deux clients sollicitant un ensemble des serveurs pour créeer leurs identitées, en effet la demande pourra se faire à n'importe quel serveur. L'utilisateur pourra choisir un serveur préecis ou laisser le choix au client XWiki de choisir un parmi les serveurs disponible, la connexion sur ces serveurs n'est pas indispensable pour se connecter sur le réseau.  
 
\paragraph{Tomber en panne}
\label{Tomber en panne} 
L'existence de plusieurs serveurs n'est pas obligatoire, mais, en cas de tomber en panne de l'un deux, les autres peuvent continuer à fournir des identitées. Dans le cas contraire, s'il y a un seul serveur, l'utilisateur ne peut créer son identité sauf en cas de disponibilité de ce dernier. 

\paragraph{Réplication des données sur les serveurs}
\label{Réplication des données sur les serveurs}
Les données sur chaque serveur peuvent \^etre identiques ou non, selon le choix de déploiement, si les données doivent \^etre identiques sur tous les serveurs, alors, une procédure de réplication des données sera nécessaire. 
    
\paragraph{Les différentes fa\c cons de gestion d'identités}
\label{Les différentes façons de gestion d'identités}

Il existe deux fa\c cons de gestion d'identités sur un réseau P2P. La première est celle de s'assurer que l'utilisateur dispose d'un compte unique sur le réseau (signature forte). Dans ce cas là il faut associer avec ces informations personnelles une signature digitale. Par exemple ses emprunts digitaux. La deuxième fa\c con est de considérer que l'utilisateur ait le droit de créer plusieurs comptes. Dans ce cas on considère que le compte lui-m\^eme doit \^etre unique.

Dans un réseau P2P tel que XWiki, en raison de besoin de mobilité et flexibilité et parce que XWiki sera utilisateur sur des machines portables, la deuxième fa\c con s'impose ; \c ca veut dire on donne la possibilité à l'utilisateur de créer plusieurs compte mais chaque compte sera traitée comme étant un utilisateur unique. Le serveur recevant la demande vérifiera bien évidement les données de l'utilisateur en question, si les informations existent dans sa base de donnéees, il avertit l'utilisateur et lui demande de changer son login et son mot de passe. D'autre contr\^ole pourrait se faire sur les informations utilisateur. Comme validation de la date et lieu de naissance ou m\^eme avoir comme réeférence unique le numéero de sa carte d'identité. 

\paragraph{Le mécanisme de demande de créer un compte utilisateur.}

Le mode de connexion doit \^etre connecté.
\begin{itemize}
\item
  L'utilisateur saisit les données liées à son compte sur le client XWiki. Il y saisit spécialement son login et son mot de passe.
\\*
\item
 XWiki signera les informations fournies par l'utilisateur (cryptage des informations avec un algorithme de chiffrage, RSA par exemple). Il les envoie à un serveur disponible sur le réseau. La recherche d'un serveur disponible peut s'effectuer d'une manière aléatoire. On peut adopter les m\^emes mécanismes de recherche et découverte entre deux pairs. Mais il s'agit ici d'une recherche spéciale pour trouver un type des pairs bien spécifiques : Les serveurs  fournissant des identités.
\\* 
\item
  En cas d'absence d'un serveur sur le réseau pour une raison ou autre, l'utilisateur ne pourra pas créer un compte. Et donc, il conservera ses données dans un endroit sur XWiki pour relancer la requ\^ete de création du compte lorsqu'un serveur soit disponible.
\\*
\item
  Le serveur qui a re\c cu les données effectue une recherche dans sa base de données pour vérifier si ces données sont déjà enregistrées. Si c'était le cas, il demande à l'utilisateur de changer ces données. Il peut aussi lui proposer plusieurs possibilités de changement, comme par exemple lorsqu'il s'agit du mot de passe ou de login.
\\*
\item
  Une fois que le serveur ait enregistré les données, il génère une référence unique et l'envoyer à l'utilisateur concerné. 
\\*
\item
  L'utilisateur peut donc, se connecter à XWiki on utilisant cette référence. Il faut noter aussi que l'utilisateur peut se connecter en mode offline sur XWiki. à cause de cette raison, les informations envoyées par le serveur doivent \^etre enregistrées sur le poste local de l'utilisateur.
\\*
\end{itemize}

\subsection{Comment limiter le nombre des identités par utilisateur}
Il existe plusieurs mécanismes permettant de limiter la multiplication des comptes pour un seul utilisateur. Ici je présente un mécanisme qui s'appelle s'inscrire pas invitation.

\paragraph{Inscription par invitation}
Le concept est simple, il s'agit de recevoir une invitation avant de s'inscrire sur XWiki. L'objectif étant de limiter la création de plusieurs identités par la m\^eme personne. On estime que celui qui invite l'utilisateur le connait personnellement. Ce fait permet de créer ce qu'on appelle un réseau social sur XWiki. Ce type du réseau a plusieurs avantages, il limite les nombres des utilisateurs malveillants ou  les utilisateurs qui ont tendance à multiplier leurs identités sans aucune raison.

\paragraph{Le scénario de l'inscription par invitation est expliqué ci-dessous}

Acteurs : 
Utilisateur (Invité) : Personne souhaitant s'inscrire et utiliser XWiki
Inviteur : administrateur du parc XWiki ou un utilisateur disposant d'un nombre limité d'invitations.

\begin{itemize}
\item 
Un utilisateur souhaitant s'inscrire et utiliser XWiki, il envoie une demande à l'inviteur
\item L'inviteur vérifie l'information de l'utilisateur en question, il vérifie notamment s'il est déjà existe dans le système ou non. Si non, il lui envoie une invitation permettant à l'utilisateur de créer un compte dans XWiki.
\item Lorsqu'il re\c coit l'invitation, l'utilisateur devienne capable de réer son compte sur XWiki avec les m\^emes informations fournies lors de l'envoi de la demande de l'invitation.  
\end{itemize}
 
\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/fig2}
  \label{fig:fig2}
\end{figure}



\section{Cas d'utilisation sécurité XWiki}

\subsection{Se connecter au système}

\paragraph{Acteurs}

\begin{itemize}
\item Utilisateur, Administrateur, Invité
\end{itemize}



\paragraph{Action}

\begin{itemize}
	\item L'acteur se connecte au système (login), pour cela,  il saisit son
nom ou son ID ou son adresse email et son mot de passe.
\end{itemize}

\paragraph{{Etat du système}}
\begin{itemize}
	\item Deux états sont possibles~: connecté au réseau ou non
connecté au réseau (l'acteur peut se connecter au
système tout en étant déconnecté du réseau) .
\end{itemize}



\paragraph{Exceptions}
\begin{itemize}
	\item Non, ID ou adresse email d'acteur incorrecte ou n'existe pas.
	\item Mot de passe incorrecte ou n'existe pas.
\end{itemize}


\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}

\begin{itemize}

\item{Service : Authentification}
\item{Technique~: Chiffrement}
\item{Composants~: JCE  (Java Cryptographie Extension), JAAS (Java
Authentification \& Autorisation Service).}
\item{Algorithmes~: algorithmes \`{a} clés symétriques +
algorithmes de hachage pour le mot de passes }
\end{itemize}



\paragraph{Diagramme de séquence}


\begin{figure}
  \centering
  \includegraphics[width=0.6\textwidth]{figures/sec-img0}
  \label{fig:sec-img0}
\end{figure}


\subsection{Se déconnecter du système}

\paragraph{Acteurs}
\begin{itemize}
\item{Utilisateur, Administrateur, Invité}
\end{itemize}
\paragraph{{Action}}



\begin{itemize}
	\item L'acteur se déconnecte du système (logout) en appuyant sur un
bouton ou en cliquant sur un élément du menu dans
le système.
\end{itemize}


\paragraph{{Etat du système}}

Deux états sont possibles~: connecté au
réseau ou non connecté au réseau.

\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}


\begin{itemize}


\item{Service ~: Authentification}





\item{Technique~: Chiffrement}





\item{Composants~: JCE  (Java Cryptographie Extension), JAAS (Java
Authentification \& Autorisation Service).}





\item{Algorithmes~: algorithmes \`{a} clés symétriques +
algorithmes de hachage pour les mot de passes }

\end{itemize}


\paragraph{Diagramme de séquence}


\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/sec-img1}
  \label{fig:sec-img1}
\end{figure}

\subsection{Créer un ou plusieurs documents }



\paragraph{{Acteurs}}


\begin{itemize}

\item{Utilisateur, Administrateur, Programmeur}

\end{itemize}



\paragraph{{Cas d'utilisations inclus}}



\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}



\paragraph{{Action}}



\begin{itemize}
	\item L'utilisateur peut créer un ou plusieurs documents en utilisant
les différentes fonctionnalités  offertes par le système.
	\item Un fichier batch doit \^{e}tre créé pour publier le(s) 
document(s) créé(s) sur le réseau
	\item L'envoi du fichier se ferra online, cependant l'utilisateur est
capable de conserver le batch sur sa machine s'il travaille en mode
offline
	\item Avant d'échanger les documents une signature du batch avec
XML-Security est nécessaire afin de sécuriser les données
\end{itemize}





\paragraph{{Etat du système}}



Deux états sont possibles~: connecté au
réseau ou non connecté au réseau.





\paragraph{{Contr\^{o}les }}



\begin{itemize}
	\item Document créé sur le poste utilisateur
	\item A la fin du traitement, l'état du  document doit \^{e}tre
sauvegardé
\end{itemize}

\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}

\begin{itemize}


\item{Service : fonctionnalités internes de l'application }





\item{Technique~: Sand Box}





\item{Composants~: Java Security}





\item{Algorithmes~: algorithmes \`{a} clés symétriques +
algorithmes de hachage pour les mot de passes }




\item{Sécurisation du message~: XML-Security + XML-Signature}

\end{itemize}




\paragraph{Diagramme de séquence}

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/sec-img2}
    \label{fig:sec-img2}
\end{figure}



\subsection{Modifier un ou plusieurs documents}

\paragraph{{Acteurs}}

\begin{itemize}

\item{Utilisateur, Administrateur, Programmeur}

\end{itemize}



\paragraph{{Cas d'utilisations inclus}}



\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}


\paragraph{{Action}}



\begin{itemize}
	\item L'utilisateur peut modifier un ou plusieurs documents en utilisant les
différentes fonctionnalités  offertes par le système.
	\item Un fichier batch doit \^{e}tre créé pour publier le(s)
document (s) modifié(s) sur le réseau
	\item Afin de sécuriser le batch, les packages XML-Security +
XML-signature seront utilisées.
	\item Avant d'échanger les documents une signature du batch avec
XML-Security est nécessaire afin de sécuriser les données
\end{itemize}





\paragraph{{Etat du système}}





Deux états sont possibles~: connecté au
réseau ou non connecté au réseau.




\paragraph{{Contr\^{o}les }}



\begin{itemize}
	\item Document créé sur le poste utilisateur
	\item A la fin du traitement, l'état du  document doit \^{e}tre
sauvegardé
\end{itemize}

\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}


\begin{itemize}

\item{Service : fonctionnalités internes de l'application }




\item{Technique~: Sand Box}





\item{Composants~: JCE  (Java Cryptographie Extension), JAAS (Java
Authentification \& Autorisation Service), XML-Security, XML-signature}





\item{Algorithmes~: algorithmes \`{a} clé symétriques }





\item{Sécurisation du message~: XML-Security + XML-Signature}


\end{itemize}



\paragraph{Diagramme de séquence}


\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/sec-img3}
  \label{fig:sec-img3}
\end{figure}


{\subsection{Envoyer un ou plusieurs patchs de mise  \`{a} jour des documents }}



\paragraph{{Acteurs}}

\begin{itemize}

\item{Utilisateur}

\end{itemize}


\paragraph{{Etendus par ces cas d'utilisations}}



\begin{itemize}
	\item Créer une page
	\item Modifier une page
\end{itemize}



\paragraph{{Action}}



\begin{itemize}
	\item A chaque création ou modification d'une page, le système met
\`{a} la disposition des autres wikis un batch incluant cette
modification
	\item Ce batch sera dispatché sur  les autres serveurs Xwiki
\end{itemize}



\paragraph{{Etat du système}}


\begin{itemize}

\item{Connecté}

\end{itemize}









\paragraph{{Contr\^{o}les }}



\begin{itemize}
	\item Système doit \^{e}tre connecté au réseau
\end{itemize}



\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}


\begin{itemize}

\item{Service : fonctionnalités internes de l'application }





\item{Technique~: Canal d'échange sécurisé}





\item{Composants~: JCE  (Java Cryptographie Extension), JAAS (Java
Authentification \& Autorisation Service).}





\item{Algorithmes~: algorithmes \`{a} clés asymétriques
(clé privée/clé publique) ou une signature
électronique(X509)}




\item{Avant d'envoyer le batch, une génération de clé
privée/clé publique doit \^{e}tre effectuée afin de
garantir une sécurité d'échange des données. Une
signature électronique peut replacer la clé asymétrique.}




\item{Sécurisation du message~: XML-Security + XML-Signature}


\end{itemize}


\subsection{Recevoir un ou plusieurs batch de mise \`{a} jour des documents}

\paragraph{{Acteurs}}

\begin{itemize}

\item{Utilisateur}

\end{itemize}


\paragraph{{Cas d'utilisations étendus}}



\begin{itemize}
	\item Créer une page
	\item Modifier une page
\end{itemize}



\paragraph{{Action}}



\begin{itemize}
	\item L'utilisateur re\c{c}oit plusieurs patchs de mis \`{a} jour des pages.
	\item Le message sera signé avec XML-signature
	\item Avec sa clé privée il décrypte le message re\c{c}u et
l'intègre dans son système
\end{itemize}





\paragraph{{Etat du système}}



\begin{itemize}

\item{Connecté}

\end{itemize}









\paragraph{{Contr\^{o}les }}



\begin{itemize}
	\item Système doit \^{e}tre connecté au réseau
\end{itemize}



\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}



\begin{itemize}

\item{Service : fonctionnalités internes de l'application }





\item{Technique~: canal d'échange sécurisé}





\item{Composants~: JCE  (Java Cryptographie Extension), JAAS (Java
Authentification \& Autorisation Service).}





\item{Algorithmes~: algorithmes \`{a} clés asymétriques
(clé privée/clé publique) ou une signature
électronique(X509). }





\item{Avant de recevoir un batch, le système doit générer
une pair de clés asymétrique afin de créer un canal
d'échange sécuriser avec la source d'envoi. }


\end{itemize}


\paragraph{Diagramme de séquence}

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/sec-img4}
  \label{fig:sec-img4}
\end{figure}

\subsection{Supprimer des pages}

\paragraph{{Acteurs}}

\begin{itemize}

\item{Adminitrateur, Utilisateur}

\end{itemize}

\paragraph{{Cas d'utilisations inclus}}
\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}



\paragraph{{Action}}



\begin{itemize}
	\item L'administrateur du système peut supprimer plusieurs pages dans le
système
	\item Un batch sera créé et envoyé aux autres serveurs pour
signaler la suppression de la page en question
\end{itemize}


\paragraph{{Etat du système}}



\begin{itemize}

\item{Connecté ou déconnecté}

\end{itemize}








\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}



\begin{itemize}

\item{Service : fonctionnalités internes de l'application }





\item{Technique~: Sand Box}





\item{Composants~: JCE  (Java Cryptographie Extension), JAAS (Java
Authentification \& Autorisation Service).}





\item{Algorithmes~: algorithmes \`{a} clé symétriques }

\end{itemize}


\subsection{Définir des droits d'accès \`{a} des pages}



\paragraph{{Acteurs}}



\begin{itemize}

\item{Administrateur}

\end{itemize}



\paragraph{{Cas d'utilisations inclus}}



\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}


\paragraph{{Action}}



\begin{itemize}
	\item L'administrateur du système doit définir le doit d'accès
aux autres utilisateurs du système
\end{itemize}


\paragraph{{Etat du système}}


\begin{itemize}

\item{Connecté ou déconnecté}

\end{itemize}



\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}

\begin{itemize}

\item{Service : fonctionnalités internes de l'application }



\item{Technique~: Sand Box}



\item{Composants~: Java Security}



\item{Algorithmes~: algorithmes de hachage pour les mot de passes }

\end{itemize}

\subsection{Création d'un utilisateur dans le système }


\paragraph{{Acteurs}}


\begin{itemize}

\item{Administrateur}

\end{itemize}

\paragraph{{Cas d'utilisations inclus}}


\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}


\paragraph{{Action}}


\begin{itemize}
	\item l'administrateur se connecte au système pour créer un ou
plusieurs utilisateurs
	\item avec la création du l'utilisateur en question, l'administrateur
définit son nom, mot de passe, profile ou toute autre information
demandée.
	\item L'administrateur sauvegarde l'information, le système met \`{a}
jour la base de données.
	\item L'administrateur se déconnecte du système ou effectue une
autre opération.
\end{itemize}


\paragraph{{Etat du système}}


\begin{itemize}

\item{Connecté}

\end{itemize}


\paragraph{{Contr\^{o}les }}


\begin{itemize}
	\item Système doit \^{e}tre connecté au réseau
\end{itemize}


\paragraph{Exceptions}


\begin{itemize}
	\item Informations de l'utilisateur sont incomplètes
\end{itemize}

\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}



\begin{itemize}


\item{Service : fonctionnalités internes de l'application }





\item{Technique~: Sand Box}





\item{Composants~: Java Security}





\item{Algorithmes~: algorithmes \`{a} clés symétriques +
algorithmes de hachage pour les mot de passes }

\end{itemize}



\subsection{Changement du mot de passe}




\paragraph{{Acteurs}}


\begin{itemize}

\item{Utilisateur, Administrateur, Programmeur}

\end{itemize}


\paragraph{{Cas d'utilisations inclus}}



\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}



\paragraph{{Action}}



\begin{itemize}
	\item L'utilisateur se connecte au système
	\item Il entre dans la page dédiée \`{a} la gestion de son profile
	\item Il saisit son ancien mot de passe
	\item Il saisit son nouveau mot de passe
	\item Le système vérifie l'ancien mot de passe
	\item Le système vérifie si le nouveau mot de passe respecte les
contraintes de sécurité
	\item Le système met \`{a} jour la base de données
\end{itemize}



\paragraph{{Etat du système}}



\begin{itemize}
	\item Connecté
\end{itemize}



\paragraph{{Contr\^{o}les }}



\begin{itemize}
	\item Système doit \^{e}tre connecté au réseau
	\item L'utilisateur doit connaitre son ancien mot de passe
\end{itemize}




\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}

\begin{itemize}


\item{Service : fonctionnalités internes de l'application }





\item{Technique~: Sand Box}





\item{Composants~: Java Security}





\item{Algorithmes~: algorithmes \`{a} clés symétriques +
algorithmes de hachage pour les mot de passes }

\end{itemize}


\subsection{Création d'un groupe d'utilisateurs.}




\paragraph{{Acteurs}}


\begin{itemize}

\item{Administrateur, Gestionnaire de ferme Wiki}

\end{itemize}



\paragraph{{Cas d'utilisations inclus}}



\begin{itemize}
	\item Se connecter au système
	\item Se déconnecter du système
\end{itemize}



\paragraph{{Action}}



\begin{itemize}
	\item l'administrateur se connecte au système
	\item Il entre dans la page dédiée \`{a} la création des groupes
d'utilisateur
	\item Pour créer un groupe, il saisit le nom du groupe
	\item Il choisit parmi les utilisateurs, ceux qui sont inclus dans le groupe
en question
	\item Il sauvegarde le groupe avec sa liste d'utilisateurs
	\item Le système met \`{a} jour la base de données
\end{itemize}



\paragraph{{Etat du système}}



\begin{itemize}
	\item Connecté
\end{itemize}



\paragraph{{Contr\^{o}les }}



\begin{itemize}
	\item Système doit \^{e}tre connecté au réseau
	\item Les utilisateurs inclus dans le groupe doivent exister déj\`{a}
dans le système
\end{itemize}




\paragraph{Besoins de sécurité (Services,Techniques, Composants, algorithmes)}




\begin{itemize}

\item{Service : fonctionnalités internes de l'application }
\item{Technique~: Sand Box}
\item{Composants~: Java Security}
\item{Algorithmes~: algorithmes \`{a} clés symétriques +
algorithmes de hachage pour les mot de passes }

\end{itemize}

\subsection{Diagramme de cas d'utilisations}

\begin{center}

\begin{figure}
  \centering
  \includegraphics[width=0.7\textwidth]{figures/sec-img5}
  \label{fig:sec-img5}
\end{figure}

\end{center}

\subsection{Tableau récapitulatif des packages}



\begin{tabular}{|p{80pt}|p{147pt}|p{65pt}|p{98pt}|}
\hline
\parbox{124pt}{\raggedright 
\textbf{Package}
} & \parbox{147pt}{\raggedright 
\textbf{Fonctionnalités et services}
} & \parbox{0pt}{\raggedright 
\textbf{Objets encapsulés }
} & \parbox{98pt}{\raggedright 
\textbf{Sous packages encapsulés }
} \\
\hline
\parbox{124pt}{\raggedright 
securityAdmin
} & \parbox{147pt}{\raggedright \begin{itemize}
	\item Se connecter/se déconnecter au système
	\item Définir des droits d'accès \`{a} des pages
	\item Création d'un utilisateur dans le système
	\item Création d'un groupe d'utilisateurs
	\item Gestion des invitations (voir l'article gestion des identités)
\end{itemize}

} & \parbox{0pt}{\raggedright 

Admin

XWikiclient

XWikiServeur




} & \parbox{98pt}{\raggedright 
{JCE  (Java Cryptographie Extension)}

{JAAS (Java Authentification \& Autorisation}
} \\
\hline
\parbox{124pt}{\raggedright 
securityUsers
} & \parbox{147pt}{\raggedright \begin{itemize}
	\item Se connecter/se déconnecter au système
	\item Créer / modifier ou supprimer un document
	\item Générer un batch
	\item Envoyer / recevoir un batch
	\item Intégrer un batch
	\item Signer un message ou un batch
	\item 
\end{itemize}

} & \parbox{0pt}{\raggedright 
Xwikiclient

XwikiServeur

Batch




} & \parbox{98pt}{\raggedright 
{JCE  (Java Cryptographie Extension)}

{JAAS (Java Authentification \& Autorisation}

{XML-Security}

{XML-signature}


} \\
\hline
\parbox{124pt}{\raggedright 
securityDocument
} & \parbox{147pt}{\raggedright \begin{itemize}
	\item Sécuriser un batch (signature)
	\item Chiffrer / déchiffrer les batch
\end{itemize}

} & \parbox{0pt}{\raggedright 
XwikiServeur

Batch


} & \parbox{98pt}{\raggedright 
{XML-Security}

{XML-signature}


} \\
\hline
\end{tabular}
\vspace{2pt}


\subsection{Vue d'ensemble}

\begin{figure}
  \centering
  \includegraphics[width=0.98\textwidth]{figures/sec-img6}
  \caption{Vue d'ensemble}
  \label{fig:sec-img6}
\end{figure}
